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The PALS architecture reduces distributed, real-time asynchronous system design to the design of 
a synchronous system under reasonable requirements. Assuming logical synchrony leads to fewer 
system behaviors and provides a conceptually simpler paradigm for engineering purposes. One of 
the current limitations of the framework is that from a set of independent "synchronous machines", 
one must compose the entire synchronous system by hand, which is tedious and error-prone. We 
use Maude's meta-level to automatically generate a synchronous composition from user-provided 
component machines and a description of how the machines communicate with each other. We 
then use the new capabilities to verify the correctness of a distributed topology control protocol for 
wireless networks in the presence of nodes that may fail. 

1 Introduction 

The design and verification of a distributed embedded system (DES) such as those in avionics, cars, 
medical systems, and sensor networks, poses serious challenges for formal verification, particularly for 
model checking verification, for at least two reasons: (i) their real-time nature has to be taken into 
consideration in their modeling and verification, and this usually makes verification harder or may require 
restrictions such as the use of time-bounded properties; (ii) their distributed nature can easily cause an 
explosion in the size of the state space, making it infeasible for a model checker to verify a system. 

The Physically Asynchronous but Logically Synchronous (PALS) architectural pattern El[6j|9l[8l has 
been recently introduced to greatly reduce the design, verification, and implementation efforts for a large 
class of DES systems, including many in avionics applications, which can be conceptually conceived to 
operate in a synchronous way, but which are in fact implemented as asynchronous systems. Up to now, 
the design of such systems has been very labor-intensive and error-prone, and their formal verification has 
been infeasible due to state space explosion even for modest-sized systems. The essence of the PALS 
idea is to allow the designer and formal verifier to specify the system as a synchronous composition 
of abstract machines, and to then automatically derive from this synchronous design a corresponding 
asynchronous version which is correct by construction. 

Conceptually, PALS can be understood as a model transformation, which takes as arguments both 
the simpler synchronous design and a collection of performance-related upper bounds, such as the max- 
imum clock skew in an underlying clock synchronization algorithm, the maximum network delay for 
message transmission between any two components, and the maximum computation time for an abstract 
machine to perform a one-step transition. The result of the PALS transformation is the corresponding 
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asynchronous system that will correctly realize the synchronous design with a provable minimal time 
period of operation. 

For model checking verification purposes, the great advantage of using PALS is that the two difficul- 
ties (i)-(ii) described above for DES model checking verification are greatly reduced. Difficulty (i), their 
real-time nature, completely goes away, since the synchronous system can be viewed as a single abstract 
machine obtained by composing the different machines connected together in the design. Such a single 
abstract machine, together with its environment specification, can then be treated as an ordinary Kripke 
structure with no explicit real-time features, and can therefore be reasoned about with standard model 
checkers. Difficulty (ii) is enormously reduced, because what in the synchronous model corresponds to a 
single state transition is achieved in its asynchronous version by possibly many transitions (at least one 
per distributed component), with possibly many interleavings. This means that the synchronous model 
will typically have many fewer states than the asynchronous one, so that it may be often possible to 
model check the synchronous model while it is infeasible to do so for its asynchronous version. Be- 
cause of the semantic equivalence between a synchronous design and its PALS asynchronous transform, 
both systems satisfy the same temporal logic properties, so that it is enough to verify the much simpler 
synchronous design. 

For the moment, the potential of PALS has not yet been fully exploited at the formal specification and 
verification levels in languages such as Maude and Real-Time Maude. For this to happen, two important 
theory transformations need to be supported and automated, namely: 

1 . the transformation performing the synchronous composition of a collection of abstract machines 
as specified by a wiring diagram connecting those machines; and 

2. the PALS transformation itself, which takes the collection of such machines and their wiring to- 
gether with the performance parameters and produces the equivalent asynchronous model. 

Thanks to the reflective features of rewriting logic and their Maude support by its META-LEVEL module, 
transformations (1) and (2) can be specified within Maude as reflective module transformations. Note, 
however, that for model checking verification purposes, since only the synchronous model needs to be 
verified, only transformation (1) is needed. 

This paper addresses this need for supporting PALS in Maude and Real-Time Maude and makes the 
following contributions: 

• It provides a meta- level implementation in Maude of transformation (1) which is both parametric 
on the wiring diagram and generic on the actual abstract machines that may then be composed 
according to the specified diagram. 

• It applies the PALS transformation for the first time to an application in the area of sensor networks, 
illustrating how it can be used to greatly simplify the formal verification of a topology control 
protocol (LMST) in the presence of failures, so that some of the nodes may fail. 

• It illustrates by the LMST example a more general method by which real-time distributed object- 
based systems can be modeled in a much simpler synchronous way using the PALS architecture, 
provided that the objects in the system in question are supposed to only communicate with each 
other at pre-established times, and change their state at those times only as a result of the messages 
they then receive. 

The remainder of the paper is organized as follows. Section|2]reviews the PALS framework, in par- 
ticular the synchronous model of design. Section [3] then describes our generic implementation in Maude 
for combining many independent synchronous machines into one large machine, accomplishing trans- 
formation (1) above. In Section [4] we then describe the LMST topology control protocol, our modeling 
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Figure 1 : A simple logic circuit. 



of it in PALS using the methods of Section[3j and prove its correctness with respect to node failure using 
Maude's LTL model checker. Finally, Section [5] contains some concluding remarks and discusses future 
work. 



2 Background: The PALS Synchronous Model 

To design a distributed, real-time system with the PALS architecture EHHHHH, one starts with a syn- 
chronous model of the system; then, a very general transformation, formally specified in QUI, takes 
the synchronous model into an asynchronous one suitable for deployment. A certain kind of bisimu- 
lation between the two systems (see Q 0) allows one to reduce (a) verification of a property against 
the asynchronous machine to (b) verification of the property against the synchronous design; where the 
properties in question are given by temporal logic formulae. The synchronous machine typically has a 
much smaller state space and can therefore be model checked more efficiently. 

In this paper we are concerned only with the synchronous model (for information on the asynchronous 
model and transformation, see EHO), the key notions of which are synchronous machines, environment, 
and wiring diagram. Consider the small logic circuit given in Figure [T] In terms of the synchronous 
model, it is comprised of three synchronous machines, M\ - Mj, an environment defined by the un- 
connected wires at the boundary box, and a wiring diagram specifying that the two xor gates get their 
inputs from the environment and send their outputs to the and gate, which finally outputs its result to the 
environment. 

Formally, a component machine M is defined as a four-tuple, (D,- ,S,D ,8 : D, x S — > S xD ), where 
Di = Di l x • • • x Di n ,n> I, specifies the inputs to the machine, D l} = D 0] x • • • x D 0m , m > 1 , specifies the 
outputs of the machine, S is its internal state, and 8 is its transition function, specifying how the state is 
updated and what outputs are produced from a given input and current state. Each of the component input 
types D (1 , . . . ,Dj n and component output types D 0l ,D 0m are assumed to be non-empty; for technical 
reasons, it is also assumed that S / 0. 

An environment is a pair (£>• ,D e a ) with D- = x • • • x ,n e > 1, the set of inputs to the en- 
vironment, and D e Q = D e (H x • • • x D e ,m e > 1, the output from the environment. Again, each of the 
D? , . . . , and D e 0l , . . . , D e 0m are assumed to be non-empty. 
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Let {Mj}j E j be a (/) indexed set of machines and E = {D\,D e ) an environment. A wiring diagram 
for {Mj}j e j and £ is a function src : / — > O, where 

7 = {(j»G(/U{e})xN| \<n <nj} and 
= {(j,n)e (JU{e})xN| l<n<mj}, 

that maps each input port to the output port, or source, from which it receives data. Ports exist as part of 
the component machines, {Mj}j e j, or as part of the environment, E. 

Returning to the example in Figure [lj each of the machines Mi - M3 have as input set B 2 , and as 
output set B; they have no internal state, but because the 5 component is required to be non-empty we 
represent the internal state with the unit type, we we denote by {*}. The output part of their transition 
functions perform exclusive-or in the case of Mi and M2, and logical and in the case of M3. The input 
type of the environment is B, since there is one input to the environment, and output type B 4 , since the 
environment furnishes four values to the machine. The wiring diagram, src, is given by 

(1.1) (1,2) ->( e ,2), (2,1) ->(e,3), 

(2.2) ^( e ,4), (3,1)^(1,1), (3,2)^(2,1), 
(e, 1)^(3,1). 

The composed machine operates just like the logic circuit, with values propagating through one level of 
logic gate per round. This could, for example, represent the time it takes for values to propagate through 
the logic elements to the output of the circuit. 



3 Automatic Synchronous Composition 

We now describe the infrastructure we have built in Maude to compose a set of synchronous machines 
into one larger machine, as illustrated above in Section [2] when we composed the three logic gates into 
a circuit. Given (a) for each machine Mj, values nj,nij specifying the number of inputs and outputs, 
respectively, of My, (b) values n e ,m e for the number of inputs and outputs of the environment, and (c) 
a wiring diagram, we automatically generate a parameterized module fl] Ch. 10] corresponding to the 
synchronous composition of a set of abstract (8 unspecified) machines composed according to the given 
wiring diagram. This is accomplished using Maude's meta-level 0] Ch. 14]. The module has a fixed 
topology, but is generic in the operation of the individual synchronous machines. The discussion in this 
section assumes a firm understanding of parameterized and meta-level programming in Maude (see 01 
for a review). 

Parameterized programming in Maude uses the notions of "theories" and "views" (see CD §8.3.1] 
and HJ §8.3.2]). Theories are used to specify a parameter's interface, and views are used to instantiate 
an interface. Theories are like regular functional and system modules in Maude, except that they do not 
need to satisfy the same conditions for executability. In general, they also may omit constructors for 
defined sorts or equations defining the declared operators since these will be mapped to other sorts and 
functions later, using a view. However, they can state axioms that any instance of the symbols in the 
parameter theory must satisfy. 

For (a) above, the user provides a term of sort Machines: 

including MAP{NzNat , IOSize} * (sort MapfNzNat , IOSize} to Machines) . 
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presumed to give a mapping from a prefix of the non-zero natural numbers, isomorphic to the index set 
J, to pairs of numbers (ray, my), the number of inputs and outputs of My, respectively. The sort for this 
pair of numbers is IOSize, defined with the following constructor 



op _#_ : NzNat NzNat -> IDSize [ctor] 



With a term of sort Machines, it is possible to generate the set of parameters for the {Mj}j e j. We 
simply iterate through the mappings, creating a new parameter for each (ray, my) pair requiring a view 
for a theory 

op smParams : Machines NzNat -> ParameterDeclList . 
eq smParams (MS , J) = 

if $hasMapping(MS, J) 

then index ('M, J) :: mkP(MS[J]) , smParams (MS , J + 
else nil fi . 



1) 



op mkP : IOSize 
eq mkP(N # M) = 



-> Qid . 

-index(-index('SM, N) , M) 



The functions index and -index take a Qid and a Nat and produce a new Qid; for example, index ( ' M , 
1) = 'Ml and -index ('M, 1) = 'M-l. The sort ParameterDeclList is pre-defined in the Maude 
prelude, in module META-MDDULE, using the following constructors which are syntactically similar to the 
source-level representation of parameters in a parameterized module 



op _::_ : Sort ModuleExpression -> ParameterDecl . 
op _,_ : ParameterDeclList ParameterDeclList 

-> ParameterDeclList [ctor assoc id: nil prec 121] 



The operator $hasMapping is pre-defined in the MAP module; it determines whether a given term has a 
mapping, and we use it to determine when we are finished iterating through the |/| modules. 

We assume a set of theories, {SM-ray-my}y 6 y, giving a general interface for a synchronous machine 
with ray inputs and my outputs; the general form of SM-ray- my is given in Figure |2j it specifies the com- 
ponent input and output sorts, product types for the input and output, projection functions, and a split 
transition function. Figure[3]shows how to instantiate a view of SM-2-1 corresponding to a "synchronous 
machine" for the two xor gates given above in Figure [T] The TUPLE module operation provides a very 
general way to create product types (see [1 , §18.3.1]); it only works in Full Maude [1 , Part II], but by 
a slight abuse of notation we employ it in Figure [3] and throughout this document, as if it can be used 
in Core Maude [ 1 , Part I]; also, we call the projection functions pil, etc. instead of pl_ which is used 
in HI §18.3.1]. In addition, it is worth noting that while it would be nice to use the TUPLE [_] module 
operation in the SM-ra-m theories, parameterized theories are not currently allowed in Maude. 

Consider again the example of Figure [T] The corresponding Machines is given by 



1 |-> 2 # 1, 2 |-> 2 # 1, 3 |-> 2 # 1 



and the value produced by smParams is 



'Ml 



'SM-2-1 



'M2 



'SM-2-1 



'M3 



'SM-2-1 



The values n e ,m e , provided by the user and corresponding to (b) above, determine the interface of 
the environment, just as the ray, my determined the interface to the component synchronous machines. 
Similar to the SM-ra-m theories, we assume theories E-n-m for the environments. These are exactly the 
same as the SM-ra-m theories, except that they omit the sort S and the transition functions deltal and 
delta2. Therefore, to generate the header for the module giving the synchronous composition of a set 
of machines we can simply use 
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fth SM-n-m is 




sorts Di Di-1 ••• Di-n . 




op '(_,•••,_') : Di-1 ••■ 


Di-n -> Di [ctor] . 


op pil : Di -> Di-1 . 




eq pil(( Xl:Di-l, ■■■ )) 


= Xl:Di-l . 


op pin : Di -> Di-n . 




pn ni 11 ( ( • • • ' Di —n ) ) 


= Xn-Di-n 


sort S . 




sorts Do Do-1 ••• Do-m . 




op '(_,■■■,_') : Do-1 ••• 


Do-m -> Do [ctor] . 


op pil : Do -> Do-1 . 




eq pil(( Xl:Do-l, ■■■ )) 


= Xl:Do-l . 


op pirn : Do -> Do-m . 




eq pim(( Xm:Do-m )) 


= Xm:Do-m . 


op deltal : Di S -> S . 




op delta2 : Di S -> Do . 




endf th 





Figure 2: The "functional theory" for a synchronous machine with n inputs and m outputs. 



op scHeader : Machines IOSize -> Header . 
eq scHeader (MS, N # M) = 

'SC { smParams (MS , 1), E :: -index (-index ( 'E, N) , M) } . 

The third component, (c) above, that we need to give is the wiring diagram. A wiring diagram is 
treated as a mapping between ports, where a port is defined as follows: 

sort MIdx . subsort NzNat < MIdx . 
op e : -> MIdx [ctor] . 
sort Port . 

op '(_,_') : MIdx NzNat -> Port [ctor] . 

Then, a wiring diagram is just (with a view for ports instantiated in the obvious way) 

including MAP{Port ,Port> * (sort Map{Port ,Port> to Wiring) . 

To generate a module for the synchronous composition of machines {Mj}j e j, and environment E, 
and a wiring diagram src, we have a function 

op gensc : Machines IDSize Wiring -> Module . 

where the arguments correspond to the three pieces of information, (a) - (c) respectively, above. The 
composed machine will be denoted by £ , following the notation of CJ|6|. 

The meta-level sort Module in META-MODULE contains the following constructor for functional mod- 
ules 

op f mod_is_sorts_ . endfm : Header ImportList SortSet SubsortDeclSet 

OpDeclSet MembAxSet EquationSet -> Module [ctor • • •] . 

The function gensc is defined at the top level by instantiating each of the arguments of the above operator 
as explained below 



Michael Katelman and Jose Meseguer 



107 



fmod X0R2 is 

including BOOL . 
including UNIT . 
including TUPLE [2] {Bool , Bool} * 

(sort Tuple{Bool,Bool> to Bool~2) 
including TUPLE [1] {Bool} * 

(sort Tuple{Bool} to Bool~l) . 

var I : Bool~2 . 
var S : Unit . 

op deltal : Bool~2 Unit -> Unit . 
eq deltal (I, S) = * . 
op delta2 : Bool~2 Unit -> Bool"l . 
eq delta2(I, S) = 

( pil(I) xor pi2(I) ) . 

endf m 

(a) Synchronous machine for an xor gate. 

Figure 3: Instantiating a synchronous machine for the xor gate using a view. 



eq gensc(MS, E, W) = 






fmod 






scHeader (MS, 


E, 


W) is 


nil 






sorts 






scSorts (MS, 


E, 


W) . 


scSubsorts(MS, 


E, 


W) 


scOpDecls (MS, 


E, 


W) 


none 






scEqs (MS, 


E, 


W) 


endfm . 







The implementation of scHeader is given above (albeit with the third argument omitted, since it 
is unused and Wiring had not been introduced). For scSorts we simply need to give names for the 
relevant sorts of <§ : (1) the input type for the composed machine, Df, (2) the state type, S s ' , and (3) the 
output type, Df . 

op scSorts : Machines IOSize Wiring -> SortSet . 
eq scSorts(MS, E, W) = 'Di~E ; 'Do'E ; 'S~E . 

Let us jump ahead briefly to define the internal state of S" , i.e., the constructor for sort S~E, since it 
requires the notion of internal node, which we will need when defining scSubsorts. Let 

N s = {(j,m) € / x N | 3 (j',n) G J x N s.t. src(/,n) = (j,m)}; 

N s is called the set of internal nodes. Then, the state of <S is defined as 

n^x n °L 

jeJ (j,m)eN 

where D J 0m denotes the sort of the m ,h output of machine Mj. For example, the set of internal nodes for 
the circuit in Figure |T| is {(1, 1), (2, 1)}, the outputs of the xor gates; therefore we generate an OpDecl 
for the state constructor as follows (where the parameters are assumed to be the same as above) 



view Xor2 from SM-2-1 to X0R2 is 
sort Di-1 to Bool . 
sort Di-2 to Bool . 
sort S to Unit . 
sort Do-1 to Bool . 
endv 

(b) View of the xor gate in the appropriate theory. 
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(op '(_',_',_',_',_') : 'M1$S 'M2$S 'M3$S 'Ml$Do-l 'M2$Do-l -> 'S~E [ctor] .) 

The general case is somewhat more tedious, but straightforward in the way described above; for details, 
see our implementation |[2l . 

The component for subsorts, scSubsorts is relatively simple to define, but fraught with a subtle 
difficulty. To start with, we generate subsort declarations for Di"E and Do~E, the inputs and outputs of 
the composed module <§, respectively; 

(subsort 'E$Do < 'Di~E .) 
(subsort 'E$Di < 'Do~E .) 

We also need to give subsort declarations for input-output port matchings, for example, to assert that the 
output sort of the xor gate M\ is a subsort of the first input of the and gate M3 

(subsort 'Ml$Do-l < 'M3$Di-l .) 

The subtle difficulty is that in Maude the semantics of subsort is that the sort on the left-hand side of 
the < symbol is a proper subsort of the sort on the right-hand side. Therefore, when using this module 
for the circuit in Figure [TJ one must guarantee that the input sorts to the and gate are strict supersorts 
of the inputs. To maintain the genericity of the parameterized module, this seems unavoidable, but one 
could go to a less generic solution where this problem would go away. In practice, we have just added 
unit O) to the input type, e.g., 

sort B00I+ . op * : -> B00I+ [ctor] . 

Finally, we must generate operators and equations for the transition function of S '. The operator 
declarations are straightforward 



(op 


>deltal~E : 


'Di'E 


'S~E -> 


'S~E 


[none] 


.) 


(op 


'delta2~E : 


'Di'E 


>S~E -> 


'Do~E 


[none] 


.) . 



The equational definition of the above functions follows the description given in ||7J |Q . The details of 
the general case are too tedious to present here, but in Figure|4]is shown the result of applying gensc to 
the appropriate arguments for the circuit in Figure [T] For full details, see our implementation Q. 

The last step is to instantiate the generated module with the appropriate views. For example, for the 
circuit in Figure [T] we use views like the one given in Figure [3] 



fmod USE-SC 


is 


including 


SC{Xor2,Xor2,And2,Env> . 


endf m 





One small difficulty in using the generated module is that it requires capturing it, saving to a file, 
and then instantiating it with appropriate views for the component machines and the environment. Of 
course, some small changes need to be made for this to work, such as removing the quotes from the 
quoted identifiers, but it is easy to write a small script for this purpose. It would of course be more 
elegant to do this entirely inside of Maude, but unfortunately the operations provided by META-LEVEL 
make this difficult. The essential problem is that because we are generating a parameterized module 
at the meta-level, to use it we need to instantiate it, and that requires generating a second meta-level 
module. However, meta-level functions such as 

op metaReduce : Module Term ~> ResultPair 

take as an argument just a single module, and not a module set; which we would need to capture both the 
generated parameterized module and its instantiation. It may simply be better to generate a specialized, 
but non-parameterized module instead of the parameterized one. 
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fmod SC{M1 :: SM-2-1.M2 :: SM-2-1.M3 :: SM-2-1.E :: E-l-4} is 
sorts Di~E Do~E S"E . 
subsort E$Di < Do~E . 
subsort E$Do < Di~E . 
subsort E$Do-l < Ml$Di-l . 
subsort E$Do-2 < Ml$Di-2 . 
subsort E$Do-3 < M2$Di-l . 
subsort E$Do-4 < M2$Di-2 . 
subsort Ml$Do-l < M3$Di-l . 
subsort M2$Do-l < M3$Di-2 . 
subsort M3$Do-l < E$Di-l . 
subsort M3$Do < E$Di . 

op '(_',_',_',_',_') : M1$S M2$S M3$S Ml$Do-l M2$Do-l -> S~E [ctor] . 

op pil : S~E -> M1$S . 

op pi2 : S~E -> M2$S . 

op pi3 : S~E -> M3$S . 

op pi-1-1 : S~E -> Ml$Do-l . 

op pi-2-1 : S~E -> M2$Do-l . 

op deltal~E : Di~E S~E -> S~E . 

op delta2~E : Di~E S~E -> Do~E . 

eq pil ((Xl:Ml$S,X2:M2$S,X3:M3$S,X4:Ml$Do-l,X5:M2$Do-l)) 
= X1:M1$S . 

eq pi2 ( (XI :M1$S,X2 : M2$S,X3 :M3$S ,X4:Ml$Do-l ,X5 :M2$Do-l) ) 
= X2:M2$S . 

eq pi3 ( (XI :M1$S,X2 :M2$S,X3 :M3$S ,X4 :Ml$Do-l ,X5 :M2$Do-l) ) 
= X3:M3$S . 

eq pi-1-1 ( (XI : M1$S , X2 : M2$S , X3 : M3$S , X4 : Ml$Do-l , X5 : M2$Do-l) ) 
= X4:Ml$Do-l . 

eq pi-2-1 ( (XI : M1$S , X2 : M2$S , X3 : M3$S , X4 : Ml$Do-l , X5 : M2$Do-l) ) 
= X5:M2$Do-l . 

eq deltal~E(X:Di~E,Y:S-E) = 

( deltal((pil(X:Di~E) ,pi2(X:Di"E) ) ,pil(Y:S~E)) 

, deltal((pi3(X:Di~E) ,pi4(X:Di~E) ) ,pi2(Y:S"E)) 

, deltaK (pi-1-1 (Y:S~E) ,pi-2-l (Y: S"E) ) ,pi3CY:S~E)) 

, pilCdelta2((pilCX:Di-E) ,pi2(X:Di~E)) ,pil(Y:S~E))) 

, pil(delta2((pi3(X:Di~E) ,pi4(X:Di~E)) ,pi2(Y:S~E))) 

) . 

eq delta2~E(X:Di"E,Y:S"E) = 

( pil (delta2( (pi-1-1 (Y:S"E) , pi-2-1 (Y: S"E) ) ,pi3(Y:S"E))) ) . 
endf m 



Figure 4: The parameterized module for the small circuit. 
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4 Verifying LMST in the Presence of Failures using PALS 



We now utilize the infrastructure described above to verify the correct operation of the local minimum 
spanning tree protocol Q in the presence of node failures. We begin with a brief introduction to the 
protocol, what it aims to achieve and its basic operation, in Section 4. 1 Then, we show how to verify the 
correctness of the LMST protocol with respect to node failure. This entails showing how each individual 
node is implemented as a synchronous machine of the kind described above (Section 4.2 1, composing 
the nodes, modeling the environment, and performing the final verification (Section 4.3 1. 



4.1 The LMST Protocol 



The purpose of a topology control protocol is to define which nodes in an ad-hoc wireless sensor network 
communicate with each other, and with what transmission power they communicate. The goal is to min- 
imize power consumption, prolong network lifetime, and maximize data bandwidth while maintaining 
network connectivity. 

In the case of the LMST protocol, a distributed, real-time algorithm is employed whereby each sensor 
node periodically updates its own local topology. The local topology of a node is the set of neighboring 
nodes to which it routes data. Each wireless node is a machine with internal quartz clock timers, a 
memory for buffering messages, and a wireless transmitter which is adjustable to different power levels. 

The periodic, real-time nature of the protocol is governed by a global constant called the round time, 
denoted rd, and each node constantly employs one of its timers, called the round timer, to count the time 
between round boundaries. When the round timer indicates that a new round has started the node adjusts 
its local topology by changing its wireless transmission strength. 

There are therefore two notions of a round, one global and one local. A global round is any real- 
world interval [t,t + rd] where t is a multiple of rd. A local round is an individual node's perception of 
the global, and is defined as any interval between successive expirations of the node's local round timer, 
which may not keep perfect time with respect to the real-world. 

The protocol is then defined by what happens when the local round timer of a node expires: 
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1. The node first broadcasts a message, called a hello message, at max- 
imum transmission strength. The hello message contains a unique 
identifier of the node and its current physical location. Hello mes- 
sages are buffered by any visible neighbor, that is, any node within 
wireless transmission range. 

2. The node reads from its message buffer all hello messages received 
during the previous round and distills from these a graph of its visi- 
ble neighbors weighted by distance. 

3. Taking the local graph of visible neighbors just distilled by the node, 
it then calculates the minimum spanning tree of that graph. 

4. The nodes in the local minimum spanning tree which are directly 
connected (one-hop away) are selected to be the node's new neigh- 
bors, meaning those to which it will transmit data during this local 
round. The node then scales its transmission power so that it can 
just reach the furthest of these neighbors. 

5. The node resets its round timer for rd, and waits for the timer to 
expire. 

As shown in Q, LMST has a number of advantageous properties, including low power usage, and 
a provably small number of neighbors for each node, which reduces medium contention and increases 
bandwidth. Furthermore, it is also shown that LMST satisfies the crucial property of maintaining network 
connectivity. That is, if the graph whose edges link the sensor nodes within wireless reach of each other 
is connected, then the considerably smaller subgraph computed by LMST is also connected. 

However, as described the protocol is somewhat idealized; it does not take into account issues that 
must be faced in a real implementation such as medium contention and node mobility. For the purpose 
of this paper, we ignore such issues. For more information of formally analyzing the LMST protocol in 
a more realistic setting, see . 



4.2 LMST Nodes as PALS Synchronous Machines 

We now demonstrate an application of the PALS architecture to verify the correctness of the LMST 
protocol in the presence of node failure . To do this we use the infrastructure of Section [3] treating the 
wireless nodes as individual synchronous machines and the environment as the determiner of which 
nodes fail during a given step. Correctness is established by showing that disconnectedness can only 
occur during a round when a node has failed. This section treats just the construction of LMST nodes as 
synchronous machines, the modeling of the environment and formula we verify the system against are 



described in Section 4.3 Assume that all of the definitions below go into a module LMST-NDDE, which 



we will use when we instantiate the view associated with it at the end of this section. 

For the sake of concreteness we consider a network with five nodes, Ni,...,Ns, with an all-to-all 
topology. However, nodes will ignore any hello message when it is outside the maximum range of the 
sending node. Furthermore, nodes that fail will output a special token, nomsg, indicating that no message 
was broadcast. 
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pr TUPLE [3] {NzNat , Nat , Nat} * 

( sort Tuple{NzNat,Nat,Nat> to Msg 

, op pil to id 

, op pi2 to xcoord 

, op pi3 to ycoord 

) . 

sort Msg+ . subsort Msg < Msg+ . 
op nomsg : -> Msg+ [ctor] . 

Given the all-to-all topology and the environment as described above, each node will have five in- 
puts: four hello message lines, one each from each of the other nodes, and one from the environment 
determining if the node fails during the current round. The input type for A^i , . . . , N5 is therefore given by 



pr TUPLE [5] {Msg+,Msg+,Msg+,Msg+, Status} * 

(sort Tuple{Msg+,Msg+,Msg+,Msg+, Status} to Reallnput) 

sort Di . subsort Reallnput < Di . 
op * : -> Di [ctor] . 



The additional constructor * is necessary because of the semantics of subsort in Maude, as described 
above in Section [3] The sort (with corresponding view) Status contains two values associated with 
constants, fail and ok. Note the sort name Di corresponds to a sort assumed in each of the SH-n-m. 
This is convenient because it allows us to avoid an explicit mapping when we eventually define the views 
for each node N\,...,Ns. 

For the state of each node, we again have to consider the two cases where the node is still running, or 
it has failed. If it is still running, it contains all of the information it needs to send a hello message plus 
its current routing table, which is a list of nodes to which it can route data through. 



pr TUPLE [4] {NzNat, Nat, Nat, NzNatList} * 

( sort Tuple{NzNat, Nat, Nat, NzNatList} to NodeSt 

, op pil to id 

, op pi2 to xcoord 

, op pi3 to ycoord 

, op pi4 to routing 

) . 

sort S . subsort NodeSt < S . 
op failed : -> S [ctor] . 



Finally, the output type for each node just contains a single piece of information for the hello message 
broadcast. 



pr TUPLE [l]{Msg+} * (sort Tuple{Msg+} to Do) . 

Therefore, each of the nodes in the network will need to instantiate a view of SM-5-1, since each has five 
inputs and a single output. 

We still need to define the transition function for each of the nodes N\,...,Ns. The Uansition function 
is exactly the same for each node 
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op deltal : Di S -> S . 
eq deltal (I, failed) = failed . 
eq deltal (I, S ) = 

if pi5(I) == fail 
then failed 

else (id(S) ,xcoord(S) ,ycoord(S) .routing' (I , S)) fi . 

op delta2 : Di S -> Do . 
eq delta2(I, failed) = (nomsg) . 
eq delta2(I, S ) = 

if pi5(I) == fail 
then (nomsg) 

else ((id(S) ,xcoord(S) ,ycoord(S))) fi . 



where routing' is defined according to the LMST algorithm given above in Section 4.1 and (for 
implementation details with respect to our experiment, see flU). Then, we can define a node simply by 
giving instantiating a view with the above sorts and functions as follows 



view LMSTNode from SM-5-1 to LMST-NODE is 
endv 



The body is empty because the module LMST-NODE named its sorts and operators using the same names 
and with the same signature as the SM-5-1 theory. 



4.3 Verification of LMST using PALS 

With synchronous machines now for all of the nodes, we still must build the composed machine, model 
the environment, and write an appropriate correctness property. The first part is greatly eased by using 
the gensc function from Section[3]with an all-to-all wiring diagram, and an appropriate abstract environ- 
ment, namely E-l-5. Taking the environment from something abstract to a concrete implementation is 
also straightforward, we essentially just need a rule for each subset of nodes that can fail during a round. 
To do this we first define an auxiliary function 



op 


natToDi'E : Nat - 


-> Di 




E 












eq 


natToDi'E(X) = 






















( if (X & (1 


<< 


0)) 


> 





then 


fail 


else 


ok 


fi 




, if (X & (1 
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D) 


> 





then 


fail 


else 


ok 


fi 




, if (X & (1 
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2)) 


> 





then 


fail 


else 


ok 


fi 




, if (X & (1 
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3)) 


> 





then 


fail 


else 


ok 


fi 




, if (X & (1 
) . 
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4)) 


> 





then 


fail 


else 


ok 


fi 



Where & is an operator for bit- wise and, and << is left-shift. As an example, to generate an input where 
every node but the first one, M\, fails, we simply use natToDi~E(l) which evaluates to. 

(ok, fail, fail, fail, fail) 

The sort Di~E is just the automatically generated type via gensc, specifically (recalling from Section[3]) 

(subsort 'E$Do < 'Di~E .) 

which is just a 5-tuple with every component of sort Status, that is, exactly the information we expect 
from the environment. Then, we add a rule to non-deterministically generate any possible output from 
the environment (equivalently, input to the device) at each step 
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crl [fromEnv] : S => deltal~E(I, S) 
if I, IS := possiblelnputsSet 



where possiblelnputsSet is a set all possible values of sort Di"E. Using the function natToDi'E 
above, it is straightforward to generate 



op genDi~EUpTo : Nat 


-> Set{Di"E> . 


eq genDi~EUpTo (0 ) 


= natToDi~E(0 ) . 


eq genDi~EUpTo(s(X)) 


= natToDi~E(s(X)) , genDi'EUpTo (X) . 


op possiblelnputsSet 


: -> Set{Di~E} . 


eq possiblelnputsSet 


= genDi~EUpTo(31) . 



We still need to define a notion of correctness for LMST. At a high level we say that the protocol is 
correct if the network always stays connected whenever there are no new node failures during a round. 
The top-level LTL formula is given by 



op 


correct? : 


-> Formula . 


eq 


correct? = 


( [] no-new-failures? -> ((0 connected?))) . 



which says, more precisely, that after the first time step it is always the case that whenever the set of 
failing nodes is stable, then during the next round the network is connected. The formula characterizing 
when there are no new node failures is defined as 



op 


no-new-failures? 


: -> Formula . 


eq 


no-new-failures? 






(failed?(l) <-> 


D failed?(D) A 




(failed? (2) <-> 


D failed? (2)) A 




(failed? (3) <-> 


failed? (3)) A 




(failed? (4) <-> 


failed? (4)) A 




(failed? (5) <-> 


failed? (5)) . 


eq 


S |= failed?(l) = 


= pil(S) == failed . 


eq 


S 1= failed? (5) = 


= pi5(S) == failed . 



that is, that the failed proposition for each node is consistent between the current state and the next state 
for every node individually. The connected? formula is more complicated, but essentially it traverses 
the routing tables of all non-failed nodes to determine if there is a multi-hop route from each non-failed 
node to every other one (see [2] for details). 

Finally, we can model check a 5 node system against correct? using Maude's LTL model checker, 
showing that for the particular topology, LMST is correct in the presence of node failure. Therefore, 
any asynchronous implementation of the system had through the PALS transformation would satisfy the 
same notion of correctness. 



Maude> red modelCheck(init , correct?) . 
reduce in CHECK : modelCheck(init , correct?) . 

rewrites: 317674 in 218ms cpu (226ms real) (1456678 rewrites/second) 
result Bool: true 
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5 Conclusions 

We have addressed the need to automatically support the synchronous composition of abstract machines 
within Maude so that the PALS architecture can be exploited for model checking purposes. This is ac- 
complished via a meta-level module transformation in Maude that can automatically generate the single 
abstract machine which is the composition of an ensemble of abstract machines connected by a wiring 
diagram. The transformation makes it easy to verify a complex asynchronous DES system by model 
checking a much simpler synchronous version where the user is responsible only for the individual ma- 
chine specifications and the wiring diagram. 

We have then illustrated how this transformation can be applied to greatly simplify the formal ver- 
ification of a key connectedness property in the LMST topology control protocol for sensor networks. 
As explained in the introduction, a sensor network protocol such as LMST is an example of a much 
broader class of distributed object-based DESs whose objects only communicate with each other at pre- 
established times, and which change their state at those times only as a result of the messages they then 
receive. It would be quite useful to identify other examples of systems within this category; also, the 
module transformation that we have presented could be specialized to object-based systems of this kind, 
so that it is not necessary to specify such objects explicitly as abstract machines. 

Besides the extension of the present work just outlined, much work remains ahead. For example, 
what is called transformation (2) in the Introduction (passing from a synchronous model to its asyn- 
chronous PALS equivalent) should also be automated at the meta-level, not for verification purposes, but 
for purposes such as asynchronous design, code generation and also for system emulation in physical 
time, when Real-Time Maude specifications are transformed into actual real-time implementations. 
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